{\rtf1\ansi\ansicpg1252\deff0\nouicompat\deflang1033{\fonttbl{\f0\fnil\fcharset0 Cambria Math;}}
{\colortbl ;\red255\green0\blue0;\red255\green255\blue0;\red0\green0\blue255;\red0\green176\blue80;\red128\green158\blue194;\red165\green165\blue165;}
{\*\generator Riched20 10.0.14393}{\*\mmathPr\mmathFont0\mwrapIndent1440 }\viewkind4\uc1 
\pard\b\f0\fs18\par

\pard\sl240\slmult1\par

\pard\par
Notes:\par
Hex 31 in 6th  place.\par
Hex 39 in 2nd\par
Hex 50, lines in 5th place, extra space at bottom\par
\par
Todo:\par
Convert JDK edition from loading from folder file to specified in code as hash strings. Dont load it from file.\par
\par
add resource dictionary to map table,\par
Go for a MVVM type of model\par
Store the main program data, then have a customizable viewer where the user can change positions, add different styling componenets move around and change colors etc.\par
    \par
then the VM aspect reads the viewer as it is and saves a file which is used to recreate the view. It reads each componenet in the tracing panel and asks what from it is considered essential in order to recreate that component as it is.\par
\par
    So it reads each  component stores basic info like text and then includes its childen\cf1\par
\par
\cf0     \cf1 Store this as a resource dictionary with keys\cf0 , so it will be an entry for each component, settings resourcedictionary with all the essential properties for that speicific component and then a resource dictionary for each of its children.\par
\par
    It will be a list or resource dictionary \cf2 of multiple levels,\cf0  not predifined level of depth, its depth will depend on how many children it has and its' childrens' complexities\par
\par
    Then when you start the program, load the resource dictionary storing all the components and put into a recursive function\par
    -The fucntion creates the component using\par
    Activator.createinstance\par
    -applys the properties using\par
    (look this up), how to apply properties to an object created with activator.createinstance\par
    -Then for each child component return to the recursive function and pass itself as the "parent" argument\par
\par
    Initial use of the recursive function will pass tracing panel as the parent and each sub component will pass its parent for the parent argument\par
\par
    The viewer then becomes customizable, and logic is decoupled between display, custom componenets, and actually stored or data that is interested in being viewed.\par
\par
    Need to see how to work the view aspect, when you want to move a path, how does it know to bring itself to the outside control? This should be only within the viewer component, shouldnt have to use the VM or M components. (something like (parent on this control. do something) but what if you dont know what the parent is capable of doing, of what type of control). Maybe a master 'organizer' which keeps track of what needs to be moved and does all the moving itself, its its own intelligence devoted for monitoring user requests and making the changes.\par
\par
Make a default "decorator" that each control subscribes to. Will be a context menu that you add to each control. A control, as part of its settings, can add additional items into the context menu if its needed. Could also do custom work and make the context menu float above the control/component horizontally with little icons/buttons. This is the VM and is loaded into the V, could be upgraded with versions over time, nicer looking icons etc. \par
\par
\cf1 - Is the control template something I could use for the project? Keep the "control" the same, and just update/increment the control template to incorporate new designs, etc?\par
\par
{\cf0{\field{\*\fldinst{HYPERLINK https://support.microsoft.com/en-us/kb/319266 }}{\fldrslt{https://support.microsoft.com/en-us/kb/319266\ul0\cf0}}}}\f0\fs18\par
(How to add control to window programmatically)\cf0\par
\par
\cf4 -Store contextmenu/decorator in VM, to be updated with each version of VM and call from V. V calls menu which is stored in VM.\cf0\par
\par
Need to think about how the V is made, use the creation file, create each component, add the custom context menu. \par
\par
Also when creating new routes from MODEL, bypass VM and add in the V decorator. Or maybe the M communicates with VM to (add new component in). Could use the activator createinstance with a blank set of settings from the Model.\par
\cf5\par
- Make newly added route maps position on the TOP of the page, so each new one goes to the top not to the bottom.\par
\cf0\par
\par
Is it better to update the VM info and then refresh the viewer based on that, OR to modify the viewer by itself and then record the view with the VM when saving or exiting?\par
\par
\par
\par
    How to create instances of the control using some activator?\par
\par
i..e..\par
\cf6\b0\i Use a Canvas control, rather than a Grid. Canvases give the control an infinite amount of space, and allow you to position them manually. It uses attached properties to keep track of position. In code, it would look like so:\par
\par
var tb = new TextBox();\par
myCanvas.Children.Add(tb);\par
tb.Width = 100;\par
Canvas.SetLeft(tb, 50);\par
Canvas.SetTop(tb, 20);\par
\cf0\b\i0\par
in VM, make all of the component generic titles, specifiying components and version numbers, then add this to an object list of the main window and then all the parts of the program reference this object list to access the components.\par
After creating the components, add them to object list and position(200,500) them within the mainwindow canvas.\par
\cf6\b0\i\par
IEnumerable<T> EnumVisualOfType<T>(Visual visual) where T : Visual\par
\{\par
    for (var i = 0; i < VisualTreeHelper.GetChildrenCount(visual); i++)\par
\cf0\b\i0\par
    Great GUI would be for each control to have a floating menu\par
of options for that control, move up, move down, access larger menu, colorize, delete, just floating above it, showing up at run time, hovering\par
\par
    "Grouping components" can be minimized.\par
\par
    Aim:\par
\par
    Switch out different display components at run-time easily without having to change the main structural data.\par
\par
    Could add components like collectors or groups of hexagram routes. Combine into one collection with a label, etc.\par
\par
    Components are upgradabble without any interferance with the main program.\par
    --Whenever you work on a component, updating some feature, you change its class name, increment the version number so you\par
    coud load \cf4 a pathtemplatev28.4\par
\cf0\par
\par
Each GUI component is its own seperate component, i.e. \cf4\i MainTextViewerV2.56,\i0  \cf0 assign each component an unchanging 'handle' in the program and then use the handle. The handle doesn't change, so the code isn't affected when you upgrade the component to a higher version number. \par
Ex:\par
\par
TextViewer = new MainTextViewerV2.56\par
\par
When you upgrade the code so that it has different behavior, then this is an upgrade of the VM code, and you can increment the version number for the VM\par
\par
{{\field{\*\fldinst{HYPERLINK http://www.dre.vanderbilt.edu/~schmidt/POSA/POSA2/event-patterns.html }}{\fldrslt{http://www.dre.vanderbilt.edu/~schmidt/POSA/POSA2/event-patterns.html\ul0\cf0}}}}\f0\fs18\par
\par
\par
Idea is to have a recipe with a data version, a VM version, and some component versions.\par
\par
So you load a "program" aka recipe file into the 'framework' of your program. The main framework or project shouldn't change, only upgrade the individual components as needed and include new 'recipe' files for different 'versions' of the application, like various perspectives you may have or different ways you could use the framework.\par
\par
A framework file is connected to the GUI and loads a VM, and a Data object.\par
The VM creates handles for all of the visual components and connects the data to the fields.\par
Visual components have their own numbers.\par
\par
\par
Then you have a seperate VM file, and a data file, in a framework project. In a different application could use the same framework and just load different VMs, data files etc. Decoupled.\par
\par
\par
\par
\par
    so old versions load old components, new versions load new components and you have a mass of components available for\par
    varying different reasons and purposes.\par
\par
    Add 'edit settings' button (a gear) in the Maps tab, uses an editor to change which display components are used in the display viewer, loads, and closes\par
\par
    THink of a way of making sure taht old versions of Route maps can be loaded in without needing to have fancy newer componnents available. Versions of VM which can be saved and loaded without it mattering which current version the program is running.\par
\par
}
 